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ABSTRACT. Present-day blockchain architectures all suffer from a number of issues not least practical means of extensi- 
bility and scalability. We believe this stems from tying two very important parts of the consensus architecture, namely 
canonicality and validity, too closely together. This paper introduces an architecture, the heterogeneous multi-chain, 
which fundamentally sets the two apart. 

In compartmentalising these two parts, and by keeping the overall functionality provided to an absolute minimum 
of security and transport, we introduce practical means of core extensibility in situ. Scalability is addressed through 
a divide-and-conquer approach to these two functions, scaling out of its bonded core through the incentivisation of 
untrusted public nodes. 

The heterogeneous nature of this architecture enables many highly divergent types of consensus systems interop- 
erating in a trustless, fully decentralised “federation”, allowing open and closed networks to have trust-free access to 
each other. 

We put forward a means of providing backwards compatibility with one or more pre-existing networks such as 
Ethereum. We believe that such a system provides a useful base-level component in the overall search for a practically 
implementable system capable of achieving global-commerce levels of scalability and privacy. 


1. PREFACE technological promise and grand talk, we have yet to see 


significant real-world deployment of present technology. 


We believe that this is down to five key failures of present 
technology stacks: — 
i How much resources are spent globally 


on processing, bandwidth and storage for the sys- 


Ga a 
transactions can be reasona y processed under 


peak conditions? 
Tsolatability: Can the s of multiple 
parties and applications be addressed to a near- 
optimal degree under the same framework? 
Developability: How well do the tools work? Do 
the APIs address the developers’ needs? Are ed- 
ucational materials available? Are the right inte- 
grations there? 
Governance: Can the network 
` evolve and adapt over time? Can 
made with sufficient i ivi 


This is intended to be a technical “vision” summary 
of one possible direction that may be taken in further de- 
veloping the blockchain paradigm together with some ra- 
tionale as to why this direction is sensible. It lays out in 
as much detail as is possible at this stage of development 
a system which may give a concrete improvement on a 
number of aspects of blockchain technology. 

It is not intended to be a specification, formal or oth- 
erwise. It is not intended to be comprehensive nor to be a 
final design. It is not intended to cover non-core aspects 
of the framework such as APIs, bindings, languages and 
usage. This is notably experimental; where parameters 
are specified, they are likely to change. Mechanisms will 
be added, refined and removed in response to community 
ideas and critiques. Large portions of this paper will likely 
be revised as experimental evidence and prototyping gives 
us information about what will work and what not. 

This document includes a core description of the pro- 
tocol together with ideas for directions that may be taken 
to improve various aspects. It is envisioned that the core 
description will be used as the starting point for an initial 


be 


decentralised system? 


Applicability: Does the technology actually ad- 


series of proofs-of-concept. A final “version 1.0” would be 
based around this refined protocol together with the ad- 
ditional ideas that become proven and are determined to 
be required for the project to reach its goals. 


1.1. History. 


09/10/2016: 0.1.0-proof1 
20/10/2016: 0.1.0-proof2 
01/11/2016: 0.1.0-proof3 
10/11/2016: 0.1.0 


2. INTRODUCTION 


Blockchains have demonstrated great promise of util- 
ity over several fields including “Internet of Things” 
(IoT), finance, governance, identity management, web- 
decentralisation and asset-tracking. However, despite the 


‘dress a burning need on its own? Is other “mid- 


dleware” required in order to bridge the gap to 
actual applications? 


In the present work, we aim to address the first two 


issues: y. That said, we believe 
the Polkadot framework can provide meaningful improve- 
ments in each of these classes of problems. 

Modern, efficient blockchain implementations such as 
the Parity Ethereum client [17] can process in excess of 
3,000 transactions per second when running on perfor- 
mant consumer hardware. However, current real-world 


, ——_— This limitation mainly origi- 


SENG IE IBURST a onan 
i i i imi ins of safety on 
ssin 3 


exacerbated by the 
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desire to support slower implementations. This is due to 


the underlying consensus architecture: 
T W kaia Cl 


the 


This applies equally to both proof-of-work (PoW) sys- 
tems such as Bitcoin [15] and Ethereum [5,23] and proof- 
of-stake (PoS) systems such as NXT [8] and Bitshares [12]: 
all ultimately suffer from the same handicap. It is a simple 
strategy that helped make blockchains a success. However, 
by tightly coupling these two mechanisms into a single unit 
of the protocol, we also bundle together multiple different 
actors and applications with different risk profiles, differ- 
ent scalability requirements and different privacy needs. 
oo often it is the case that in a 
desire for broad appeal, a network adopts a degree of con- 
servatism which results in a lowest-common-denominator 
optimally serving few and ultimately leading to 
, sometimes 
dramatically so. 

Some systems such as e.g. Factom [21] drop the state- 
transition mechanism altogether. However, much of the 
utility that we desire requires the ability to transition state 
according to a shared state-machine. Dropping it solves 
an alternative problem; it does not provide an alternative 
solution. 

It seems clear, therefore, that one reasonable direction 
to explore as a route to a scalable decentralised compute 
platform is to i 

. And, perhaps unsurpris- 
ingly, this is the strategy that Polkadot adopts as a solu- 
tion to scalability. 


2.1. Protocol, Implementation and Network. Like 
Bitcoin and Ethereum, Polkadot refers at once to a net- 
work protocol and the (hitherto presupposed) primary 
public network that runs this protocol. Polkadot is in- 
tended to be a free and open project, the protocol speci- 
fication being under a Creative Commons license and the 
code being placed under a FLOSS license. The project is 
developed in an open manner and accepts contributions 
where ever they are useful. A system of RFCs, not unlike 
the Python Enhancement Proposals, will allow a means of 
publicly collaborating over protocol changes and upgrades. 

Our initial implementation of the Polkadot protocol 
will be known as the Parity Polkadot Platform and will 
include a full protocol implementation together with API 
bindings. Like other Parity blockchain implementations, 
PPP is designed to be a general-purpose blockchain tech- 
nology stack, neither uniquely for a public network nor for 
private/consortium operation. The development of it thus 
far has been funded by several parties including through 
a grant from the British government. 

This paper nonetheless describes Polkadot under the 
context of a public network. The functionality we envi- 
sion in a public network is a superset of that required in 
alternative (e.g. private and/or consortium) settings. Fur- 
thermore, in this context, the full scope of Polkadot can 
be more clearly described and discussed. This does mean 


lhttps://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 
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the reader should be aware that certain mechanisms may 
be described (for example interoperation with other pub- 
lic networks) which are not directly relevant to Polkadot 
when deployed under non-public (“permissioned” ) situa- 
tions. 


2.2. Previous work. Decoupling the underlying consen- 
sus from the state-transition has been informally proposed 
in private for at least two years—Max Kaye was a pro- 
ponent of such a strategy during the very early days of 
Ethereum. 

A more complex scalable solution known as Chain 
fibers, dating back to June 2014 and first published later 
that year, made the case for a single relay-chain and mul- 
tiple homogeneous chains providing a transparent inter- 
chain execution mechanism. Decoherence was paid for 
through transaction latency—transactions requiring the 
coordination of disparate portions of the system would 
take longer to process. Polkadot takes much of its ar- 
chitecture from that and the follow-up conversations with 
various people, though it differs greatly in much of its de- 
sign and provisions. 

While there are no systems comparable to Polkadot 
actually in production, several systems of some relevance 
have been proposed, though few in any substantial level of 
detail. These proposals can be broken down into systems 
which drop or reduce the notion of a globally coherent 
state machine, those which attempt to provide a globally 
coherent singleton machine through homogeneous shards 
and those which target only heterogeneity. 


2.2.1. Systems without Global State. Factom [21] is a sys- 
tem that demonstrates canonicality without the according 
validity, effectively allowing the chronicling of data. Be- 
cause of the avoidance of global state and the difficulties 
with scaling which this brings, it can be considered a scal- 
able solution. However, as mentioned previously, the set 
of problems it solves is strictly and substantially smaller. 

Tangle [18] is a novel approach to consensus systems. 
Rather than arranging transactions into blocks and form- 
ing consensus over a strictly linked list to give a glob- 
ally canonical ordering of state-changes, it largely aban- 
dons the idea of a heavily structured ordering and instead 
pushes for a directed acyclic graph of dependent trans- 
actions with later items helping canonicalise earlier items 
through explicit referencing. For arbitrary state-changes, 
this dependency graph would quickly become intractable, 
however for the much simpler UTXO model? this becomes 
quite reasonable. Because the system is only loosely co- 
herent and transactions are generally independent of each 
other, a large amount of global parallelism becomes quite 
natural. Using the UTXO model does have the effect 
of limiting Tangle to a purely value-transfer “currency” 
system rather than anything more general or extensible. 
Furthermore without the hard global coherency, interac- 
tion with other systems—which tend to need an absolute 
degree knowledge over the system state—becomes imprac- 
tical. 


2unspent transaction output, the model that Bitcoin uses whereby the state is effectively the set of address associated with some value; 
transactions collate such addresses and reform them into a new set of addresses whose sum total is equivalent 
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2.2.2. Heterogeneous Chain Systems. Side-chains [3] is a 
proposed addition to the Bitcoin protocol which would al- 
low trustless interaction between the main Bitcoin chain 
and additional side-chains. There is no provision for any 
degree of ‘rich’ interaction between side-chains: the in- 
teraction would be limited to allowing side-chains to be 
custodians of each other’s assets, effecting—in the local 
jargon—a two-way peg’. The end vision is for a frame- 
work where the Bitcoin currency could be provided with 
additional, if peripheral, functionality through pegging it 
onto some other chains with more exotic state transition 
systems than the Bitcoin protocol allows. In this sense, 
side-chains addresses extensibility rather than scalability. 

Indeed, there is fundamentally no provision for the va- 
lidity of side-chains; tokens from one chain (e.g. Bitcoin) 
held on behalf of a side-chain are secured only by the 
side-chain’s ability to incentivise miners to canonicalise 
valid transitions. The security of the Bitcoin network 
c 

_blockchains. Furthermore, a protocol for ensuring Bitcoin 
miners merge-mine (that is duplicate their canonicalisa- 
tion power onto that of the side-chain) and, more impor- 
tantly, validate the side-chain’s transitions is outside the 
scope of this proposal. 

Cosmos [10] is a proposed multi-chain system in the 
same vein as side-chains, swapping the Nakamoto PoW 
consensus method for Jae Kwon’s Tendermint algorithm. 
Essentially, it describes multiple chains (operating in 
zones) each using individual instances of Tendermint, to- 
gether with a means for trust-free communication via a 
master hub chain. This interchain communication is lim- 
ited to the transfer of digital assets (“specifically about to- 
kens” ) rather than arbitrary information, however such in- 
terchain communication does have a return path for data, 
e.g. to report to the sender on the status of the transfer. 

Validator sets for the zoned chains, and in particular 
the means of incentivising them, are, like side-chains, left 
as an unsolved problem. The general assumption is that 
each zoned chain will itself hold a token of value whose in- 
flation is used to pay for validators. Still in the early stages 
of design, at present the proposal lacks comprehensive de- 
tails over the economic means of achieving the scalable 
certainty over global validity. However, the loose coher- 
ence required between the zones and the hub will allow 
for additional flexibility over the parameters of the zoned 
chains compared to that of a system enforcing stronger 
coherence. 


2.2.3. Casper. As yet no comprehensive review or side- 
by-side comparison between Casper [6] and Polkadot 
have been made, though one can make a fairly sweeping 
(and accordingly inaccurate) characterisation of the two. 
Casper is a reimagining of how a PoS consensus algorithm 
could be based around participants betting on which fork 
would ultimately become canonical. Substantial consider- 
ation was given to ensuring that it 
and have some additional de- 
gree of scalability on top of the basic Ethereum model. As 
such, Casper to date has tended to be a substantially more 
than Polkadot and its forebears, and a 
substantial deviation from the basic blockchain format. It 


3 


Rather, Polkad 
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remains unseen as to how Casper will iterate in the future 
and what it will look like should it finally be deployed. 

While Casper and Polkadot both represent interest- 
ing new protocols and, in some sense, augmentations of 
Ethereum, there are substantial differences between their 
ultimate goals and paths to deployment. Casper is an 
Ethereum Foundation-centered project originally designed 
to be a PoS alteration to the protocol with no desire to 
create a fundamentally scalable blockchain. Crucially, it is 
designed to be a hard-fork, rather than anything more ex- 
pansive and thus all Ethereum clients and users would be 
required to upgrade or remain on a fork of uncertain adop- 
tion. As such, deployment is made substantially more dif- 
ficult as is inherent in a decentralised project where tight 
coordination is necessary. 

Polkadot differs in several ways; first and foremost, 


bed. It is built to be a ee aee E; 


assimilate new blockchain technology as it becomes avail- 


able ihoni Up aioe gaiek derogare opndiesti rm 
or hard forks. e already envision several use cases such 


as encrypted consortium chains and high-frequency chains 
with very low block times that are unrealistic to do in 
any future version of Ethereum currently envisioned. Fi- 
nally, the coupling between it and Ethereum is extremely 
loose; no action on the part of Ethereum is necessary to 
enable trustless transaction forwarding between the two 
networks. 

In short, while Casper/Ethereum 2.0 and Polkadot 
share some fleeting similarities we believe their end goal 
is substantially different and that rather than competing, 
the two protocols are likely to ultimately co-exist under a 
mutually beneficial relationship for the foreseeable future. 


3. SUMMARY 
in. This 
means that unlike previous blockchain implementations 
which have focused on providing a single chain of varying 


degrees of generality over potential applications, Polkadot 
itself is designed to 


‘parallelised” 
though there is no specific need for 
them to be blockchain in nature. 
In other words, Polkadot may be considered equiva- 
s (e.g. the set containing 
Ethereum, Ethereum Classic, Namecoin and Bitcoin) ex- 
cept for two very important points: 


These points are why we consider Polkadot to be “scal- 


In principle, - 
—scaled out—over _ 
Since all aspects of each 
parachain may be conducted in parallel by a different seg- 
ment of the Polkadot network, the system has some ability 
to scale. Polkadot provides a rather bare-bones piece of 


as opposed to a one-way peg which is essentially the action of destroying tokens in one chain to create tokens in another without the 
mechanism to do the converse in order to recover the original tokens 
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infrastructure leavi offloaded into middleware, placed 
is is a conscious de- 


cision intended to reduce development risk, enabling the General: no unnecessary requirement, constraint 
requisite software to be developed within a short time span gD 
and with a good level of confidence over its security and olkadot should be a test bed for consensus sys- 
robustness. tem development which can be optimised through 


making the model into which extensions fit as ab- 
stract as possible. 


3.1. The Philosophy of Polkadot. Polkadot should Robust: Polkadot should i 

provide an absolute i i i In Mery a ty 
i right through , this also means decentralising to minimise ~ 

the risk spectrum from production-capable mature designs the vectors for high-reward attacks. 


to nascent ideas. By providing strong guarantees over se- 
_ curity, isolation and communication, a 4. PARTICIPATION IN POLKADOT 


There are four basic roles in the upkeep of an Polkadot 
network: collator, fisherman, nominator and validator. In 
one possible implementation of Polkadot, the latter role 
may actually be broken down into two roles: basic valida- 
tor and availability guarantor; this is discussed in section 


Indeed, we foresee various experimental blockchains push- 
ing the properties of what could be considered sensible 
today. 

We see conservative, high-value chains similar to 
Bitcoin or Z-cash [20] co-existing alongside lower-value 


“theme-chains” (such marketing, so fun) and test-nets 6.5.3. 
with zero or near-zero fees. We see fully-encrypted, 
“dark”, consortium chains operating alongside—and even © Collator © Fisherman V Nominator 
providing services to—highly functional and open chains 
such as those like Ethereum. We see experimental new provides block 
candidates 


VM-based chains such as a subjective time-charged wasm reports 


for 


chain being used as a means of outsourcing difficult com- monitors bad approves 
pute problems from a more mature Ethereum-like chain behaviour to 
or a more restricted Bitcoin-like chain. 
i Polkadot will inherently vate A 
t ikely based alidators —————______—_. alidators 
aee] o E (this group) becomes (other groups) 


on existing stable political systems and having a bicam- 
eral aspect similar to the Yellow Paper Council [24]. As 
theultimate authority, the underlying stakable token hold- FIGURE 1. The interaction between the 
“ers would have “referendum” control. To reflect the users’ four roles of Polkadot. 

need for development but the developers’ need for legiti- 
macy, we expect a reasonable direction would be to form 
the (made up of 


bonded validators) and a “technical” committee made up 
of major client developers and ecosystem players. The 


body of intai 
i augment, reparam- 


eterise, replace or dissolve this structure, something we 
don’t doubt the eventual need for: in the words of Twain 
“Governments and diapers must be changed often, and for 
the same reason”. 

Whereas reparameterisation is typically trivial to ar- 
range within a larger consensus mechanism, more qualita- 


; ; is proces: 
tive changes such as replacement and augmentation would CEE pH 


involves 


blocks. The 


4.1. Validators. A validator is the highest charge and 
helps seal new blocks on the Polkadot network. The val- 


idator’s role is conti 


being deposited, though w 
‘nominate one or more validators to act for them and as 


such som i 
but rather by these 


nominators. 
A validator 
tion with hi 


t implementa- 


likely need to be either non-automated “soft-decrees” (e.g. 
through the canonicalisation of a block number and the 


hash of a document formally specifying the new protocol) sines thg 5 

or necessitate the core consensus mechanism to contain a Ta ae TER iE ge 
sufficiently rich language to describe any aspect of itself aaa 
which may need to change. The latter is an eventual aim, 

however, the former more likely to be chosen in order to enamel lon ean ie nae ore lines 
facilitate a reasonable development timeline. f 


Polkadot’s primary tenets and the rules within which 


is involves 
we evaluate all design decisions are: i 
updating the state of the transaction queues (essentially 
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to find consensus 
under the rules of our chosen consensus ee, ord 
i initi , this is throug 


re- 


sult in the 


conspiring to provide an invali 
i hich is 


uch as double-signing or 
block i 


In some sense, validators are similar to the mining pools 
of current PoW blockchains. 
party 


4.2. Nominators. A nominator is 
i They 


have no additional role except to place risk capital and as 
such to si i (or 
set thereof) to act responsibly in their maintenance of the 


network. They receive a pro-rata increase or reduction, 


COo 


Together with collators, next, nominators are in some 
sense similar to the miners of the present-day PoW net- 
works. 


4. . Transaction collators (collators for short) 
are parties who 


meaning that they retain all necessary 
information to be able to author new blocks and execute 
transactions in much the same way as miners do on cur- 
rent PoW blockchains. Under normal circumstances, they 
will 


The precise nature of the relationship between colla- 
tors, nominators and validators will likely change over 
time. Initially, we expect collators to work very closely 
with validators, since there will be only a few (perhaps 
only one) parachain(s) with little transaction volume. The 
initial client implementation will include RPCs to allow a 
parachain collator node to unconditionally supply a (relay- 
chain) validator node with a provably valid parachain 
block. As the cost of maintaining a synced version of 
all such parachains increases, we expect to see additional 
infrastructure in place which will help separate out the 
duties to independent, economically-motivated, parties. 

Eventually, we expect to see collator pools who vie to 
collect the most transaction fees. Such collators may be- 
come contracted to serve particular validators over a pe- 
riod of time for an on-going share in the reward proceeds. 
Alternatively, “freelance” collators may simply create a 
market offering valid parachain blocks in return for a com- 
petitive share of the reward payable immediately. Simi- 
larly, decentralised nominator pools would allow multiple 
bonded participants to coordinate and share the duty of a 
validator. This ability to pool ensures open participation 
leading to a more decentralised system. 


4.4. Fishermen. Unlike the other two active parties, 


fishermen are not directly related to the block-authoring 
process. Rather they are 


motivated by a large one-off reward. Precisely due to 
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the existence of fishermen, we expect events of misbe- 
haviour to happen seldom, and when they do only due to 
the bonded party being careless with secret key security, 
rather than through malicious intent. The name comes 
from the expected frequency of reward, the minimal re- 
quirements to take part and the eventual reward size. 


Fishermen get their reward through a timely proof that, 
at least one bonded party acted illegally. legal actions 


ag: Ce 


. To prevent over-rewarding or the compromise and 
illicit use of a session’s secret key, the base reward for 
providing a single validator’s illegally signed message is 
minimal. This reward increases asymptotically as more 
corroborating illegal signatures from other validators are 
provided implying a genuine attack. The asymptote is set 
at 66% following our base security assertion that at least 
two-thirds of the validators act benevolently. 

Fishermen are somewhat similar to “full nodes” in 
present-day blockchain systems that the resources needed 
are relatively small and the commitment of stable uptime 


and bandwidth is not necessary. Fishermen differ in so 
much ee A. This bond prevents 
yi : ; z 
resources. It is ouaaataly ailhdeewable probably no 


more than the equivalent of a few dollars and may lead 
to reaping a hefty reward from spotting a misbehaving 
validator. 


5. DESIGN OVERVIEW 


This section is intended to give a brief overview of the 
system as a whole. A more thorough exploration of the 
system is given in the section following it. 


5.1. Consensus. On the relay-chain, Polkadot achieves 
low-level consensus over a set of mutually agreed valid 
blocks through a 


modern asynchronous Byzantine fault- 
= — rr he algorithm will b 
y the simple Tendermint [11 


[14]. The latter provides an 
efficient and fault-tolerant consensus over an arbitrarily 
defective network infrastructure, given a set of mostly be- 
nign authorities or validators. 

For a proof-of-authority (PoA) style network, this alone 
would be sufficient, however Polkadot is imagined to be 
also deployable as a network in a fully open and public 
situation without any particular organisation or trusted 
authority required to maintain it. As such we need a 
means of determining a set of validators and incentivising 
them to be honest. For this we utilise PoS based selection 
criteria. 


5.2. Proving the Stake. We assume that the network 


will have some means of measuring how much “stake” 
any particular account has. For ease of comparison to 
pre-existing systems, we will call the unit of measurement 
“tokens”. Unfortunately the term is less than ideal for a 
number of reasons, not least that being simply a scalar 
value associated with an account, there is no notion of 
individuality. 

We imagine v: (at most 
once per day but perhaps as seldom as once per quarter), 


through’ Nominated Proof-of-Stake (NPoS) schem 
centivisation can happen t f 


POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 6 


Transaction 
(submitted by 
external actor) 

* 


( ee Propagated transactions 
% 


% 


_— Block candidate submission 
6 
Validator swarm 


(each coloured by its 
designated parachain) 


2nd order 
Relay-chain 


Fisherman `: 


Parachain community 
Account 
Inbound transaction 


Interchain transactions 
(managed by validators) 


Outbound transaction 


Parachain 
queues and I/O 


Parachain 


Parachain 
bridge 


> 


Vv 


Virtual parachain 
(e.g. Ethereum) 


FIGURE 2. A summary schematic of the Polkadot system. This shows collators collecting and propa- 
gating user-transactions, as well as propagating block candidates to fishermen and validators. It also 
shows how an account can post a transaction which is carried out of its parachain, via the relay-chain 
and on into another parachain where it can be interpreted as a transaction to an account there. 


(up to 100% 


per year, though more likely around 10%) together with | 


While monetary base ex- ve 


pansion typically leads to inflation, since all token owners To ensure newly-syncing clients — 
would have a fair opportunity at participation, no token- SSRI AP RAGS RP EGA gO ERIN A 
holder would need to suffer a reduction in value of their Teega of at most the same period of the 
holdings over time provided they were happy to take a validators’ bon iquidation) that hard-code recent check-_ 


role in the consensus mechanism. A particular proportion point block hashes into clients. This plays well with a fur- 


of tokens would be targeted for the staking process; the ther footprint-reducing measure of “finite chain length” or 
effective token base expansion would be adjusted through periodic reseting of the genesis-block. 
a market-based mechanism to reach this target. 

Validators are bonded heavily by their stakes; exiting 5.3. Parachains and Collators. Each parachain gets 


validators’ similar security affordances to the relay-chain: the 
[ins (perhaps around 3 = This aA e tet E 
bond-liq period allows future misbehaviour tobe en _ 

up until the periodic checkpointing of the chain. ble following confirmation. This is a similar security guar- 
Misbehaviour results in punishment, such as reduction of antee to that offered by Bitcoin’s side-chains and merge- 
reward or, in cases which intentionally compromise the mining. Polkadot, however, also provides strong guaran- 
network’s integrity, the validator losing some or all of its . This 
stake to other validators, informants or the stakeholders 
as a whole (through burning). For example, a validator 
who attempts to ratify both branches of a fork (sometimes 
known as a “short-range” attack) may be identified and setup generally implies that 
punished in the latter way. The specific 
means of determining the partitioning is outside the scope 


4Such an attack is where the adversary forges an entirely new chain of history from the genesis block onwards. Through controlling a 
relatively insignificant portion of stake at the offset, they are able to incrementally increase their portion of the stake relative to all other 
stakeholders as they are the only active participants in their alternative history. Since no intrinsic physical limitation exists on the creation 
of blocks (unlike PoW where quite real computational energy must be spent), they are able to craft a chain longer than the real chain in a 
relatively short timespan and potentially make it the longest and best, taking over the canonical state of the network. 
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of this document but would likely be based either around 
a commit-reveal framework similar to the RanDAO [19] or 
use data combined from previous blocks of each parachain 
under a cryptographically secure hash. 


pain of bond confiscation). Validity revolves around two 


important points; firstly that it is intrinsically valid—that 


2 Valida- 
tors containing no ex- 
ternal “transactions” data, but may run the risk of get- 
ting a reduced reward if they do. They work alongside 
a parachain gossip protocol with collators—individuals 
who collate transactions into blocks and provide a non- 
interactive, zero-knowledge proof that the block consti- 
tutes a valid child of its parent (and taking any transaction 


fees for their trouble). 
It is 


ion: there is no fundamental no- 
tion of “compute-resource metering” or “transaction fee” 
imposed by the relay-chain. There is also no direct en- 
forcement on this by the relay-chain protocol (though it 
is unlikely that the stakeholders would choose to adopt 
a parachain which didn’t provide a decent mechanism). 
This is an explicit nod to the possibility of chains unlike 
Ethereum, e.g. a Bitcoin-like chain which has a much sim- 
pler fee model or some other, yet-to-be-proposed spam- 
prevention model. 
Polkadot’s relay-chain itself will probably exist as an 
Ethereum-like accounts and state chain, possibly an EVM- 
derivative. Since the relay-chain nodes will be Sees MEE a to 


do substantial other ri ong ge taco | ore cn nh sia us fn peratia 


5.4 atercpolnsanimmmnication The critical final in- 
gredient of Polkadot is interchain communication. Since 


parachains can have some sort of information channel be- 
tween them, we allow ourselves to consider Polkadot a 
scalable multi-chain. In the case of Polkadot, the commu- 
nication is as simple as can be: 


ansactionsiexeuntingima) 
parachain are (according to the logic of that chain) able to- 


nd 
fo) ike ex ons 


on production blockchains, they are fully asynchronous 


5Such a task might be shared between validators or could become 


availability guarantors. 


Sioa SaaS LE transactions s 
— 2 such as those external a 
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Account sends post: 
entry placed in 
egress Merkle tree 
for destination 
parachain 


Account receives post: 
entry removed from 
ingress Merkle tree 


Source: shares 
data with next block’s 
validators 


Destination: gets 
data from prior 
block’s validators. 


proof-of-post stored in 
parachain egress Merkle 
tree 


routed reference placed 
in destination parachain’s 
ingress Merkle tree 


FIGURE 3. A basic schematic showing 
the main parts of routing for posted 
transactions (” posts”). 


To ensure minimal implementation complexity, min- 
imal risk and minimal straight-jacketing of future 
in architecture 


ment, providing the ee 
CMG, Unlike com- 
mon current systems such as Bitcoin and Ethereum, in- 
terchain transactions 


aged through 
A system such as that proposed for 


Ethereum’s Serenity release [7] would be a simple means 
of managing such a cross-chain resource payment, though 
we assume others may come to the fore in due course. 


es ue coun 


E is the task of the relay-chain maintainers to 


vent a parachain from spamming another parachain with 


transactions, for a transaction to be sent, it is required 


queue is too large after block processing, then it is con- 


ntil reduced back below the 


limit. These 


allowing parachains to determine each other’s saturation 
status; this way a 

to a stalled destination may be 
(Though 


to post a transaction 


5.5. Polkadot and Ethereum. Due to Ethereum’s Tur- 
ing completeness, we expect there is ample opportu- 
nity for Polkadot and Ethereum to be interoperable with 
each other, at least within some easily deducible secu- 


rity bounds. In short 


the designate task of a set of heavily bonded validators known as 
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By 
a ct. In the other direction, 


Rae LATTER (events) 
Co rear 


5.5.1. Polkadot to Ethereum. Through the choice of a 


‘mechanism, we are able to get a secure consensus with an 


s. 
In a system with a total of 144 validators, a block time of 
4 seconds and a 900-block finality (allowing for malicious 
behaviour such as double-votes to be reported, punished 
and repaired), the validity of a block can reasonably be 
considered proven through as little as 97 signatures (two- 
thirds of 144 plus one) and a following 60-minute verifica- 
tion period where no challenges are deposited. 

Ethereum is able to host a “break-in contract” which 
can maintain the 144 signatories and be controlled by 
them. Since elliptic curve digital signature (ECDSA) re- 
covery takes only 3,000 gas under the EVM, and since 
we would likely only want the validation to happen on a 
super-majority of validators (rather than full unanimity), 
the base cost of Ethereum confirming that an instruction 
was properly validated as coming from the Polkadot net- 
work would be no more than 300,000 gas—a mere 6% of 
the total block gas limit at 5.5M. Increasing the num- 
ber of validators (as would be necessary for dealing with 
dozens of chains) inevitably increases this cost, however 
it is broadly expected for Ethereum’s transaction band- 
width to grow over time as the technology matures and 
infrastructure improves. Together with the fact that not 
all validators need to be involved (e.g. only the highest 
staked validators may be called upon for such a task) the 
limits of this mechanism extend reasonably well. 

Assuming a daily rotation of such validators (which is 
fairly conservative—weekly or even monthly may be ac- 
ceptable), then the cost to the network of maintaining 
this Ethereum-forwarding bridge would be around 540,000 
gas per day or, at present gas prices, $45 per year. A ba- 
sic transaction forwarded alone over the bridge would cost 
around $0.11; additional contract computation would cost 
more, of course. By buffering and bundling transactions 
together, the break-in authorisation costs can easily be 
shared, reducing the cost per transaction substantially; 
if 20 transactions were required before forwarding, then 
the cost for forwarding a basic transaction would fall to 
around $0.01. 

One interesting, and cheaper, alternative to this multi- 
signature contract model would be to use threshold sig- 
natures in order to achieve the multi-lateral ownership se- 
mantics. While t 
such as Schnorr signatures a . Ethereum 
plans to introduce primitives which would make such 
schemes cheap to use in the upcoming Metropolis hard- 
fork. If such a means were able to be utilised, the gas costs 
for forwarding a Polkadot transaction into the Ethereum 
network would be dramatically reduced to a near zero 
overhead over and above the basic costs for validating the 
signature and executing the underlying transaction. 


ee ee 


In this model, Polkadot’s validator nodes would have 
to do little other than sign messages. To get the trans- 
actions actually routed onto the Ethereum network, we 
assume either validators themselves would also reside on 
the Ethereum network or, more likely, that small bounties 
be offered to the first actor who forwards the message on 
to the network (the bounty could trivially be paid to the 
transaction originator). 


Busnes Sire ORaE A transactions to be 
forwarded from Ethereum to Polkadot uses the simple no- 
tion of logs. When an Ethereum contract wishes to dis- 
patch a transaction to a particular parachain of Polkadot, 
it need simply ial “ - zd 
The break-out contract 


_ be required and issue a logging instruction so that its ex- 


serti 


Of the latter two conditions, validity is perhaps the 
most straightforward to prove. In principle, the only re- 


(i.e. appointed validator nodes) 


. Unfor- 
this is itself a rather heavy dependency. 
t method would be to 


ee ab a oan i (con- 
tained in the block receipt) are valid. Such “SPV-like”® 


proofs may yet require a substantial amount of informa- 

tion; conveniently, they would typically not be needed at ~ 
eir 

as a “fisher- 


man”, see 6.2.3) p a 
(specifically that the state root or receipt roots were im- 
postors). 

On a non-finalising PoW network like Ethereum, the 
canonicality is impossible to proof conclusively. To ad- 
dress this, applications that attempt to rely on any kind 
of chain-dependent cause-effect wait for a number of “con- 
firmations”, or until the dependent transaction is at some 

particular depth within the chain. On Ethereum, this 
depth varies from 1 block for the least valuable transac- 
tions with no known network issues to 1200 blocks as was 
the case during the initial Frontier release for exchanges. 
On the stable “Homestead” network, this figure sits at 

for most exchanges, and we would likely take 
a similar parameter. 

So we can imagine our Polkadot-side Ethereum- 
interface to have some simple functions: to be able to 
accept a new header from the Ethereum network and val- 
idate the PoW, to be able to accept some proof that a 
particular log was emitted by the Ethereum-side break- 
out contract for a header of sufficient depth (and forward 
the corresponding message within Polkadot) and finally 
to be able to accept proofs that a previously accepted but 
not-yet-enacted header contains an invalid receipt root. 

elf (and 
any SPV proofs or validity/canonicality refutations) into 


SSPV refers to Simplified Payment Verification in Bitcoin and describes a method for clients to verify transactions while keeping only 


a copy of all blocks headers of the longest PoW chain. 
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This 


rough some protocol- 
intrinsic means or through a contract maintained on the 
relay chain. 


5.6. Polkadot and Bitcoin. Bitcoin interoperation 
presents an interesting challenge for Polkadot: a so-called 
“two-way peg” would be a useful piece of infrastructure 
to have on the side of both networks. However, due to 
the limitations of Bitcoin, providing such a peg securely is 
a non-trivial undertaking. Delivering a transaction from 
Bitcoin to Polkadot can in principle be done with a pro- 
cess similar to that for Ethereum; a “break-out address” 
controlled in some way by the Polkadot validators could 


“break-out address” 


trolled by those same validators for later dispersal. 
The however is SMCS. 
. Unlike 


Ethereum which is able to make arbitrary decisions based 


would then, in principle, be con- 


upon combinations of signatures is substantially 


more limited, with most 
Ss . Ex- 


tending this to 36, or indeed thousands as might ulti- 
mately be desired, is impossible under the current proto- 
col. One option is to alter the Bitcoin protocol to enable 
such functionality, however so-called “hard forks” in the 
Bitcoin world are difficult to arrange judging by recent at- 
tempts. One possibility is the use of threshold signatures, 
cryptographic schemes to allow a singly identifiable public 
key to be effectively controlled by multiple secret “parts”, 
some or all of which must be utilised to create a valid sig- 
nature. Unfortunately, threshold signatures compatible 
with Bitcoin’s ECDSA are computationally expensive to 
create and of polynomial complexity. Other schemes such 
a Schnorr signatures provide far lower costs, however the 
timeline on which they may be introduced into the Bitcoin 
protocol is uncertain. 

Since the ultimate security of the deposits rests with 

i bonded validators, one other opti 


: ply setting an tao limit of 
the once of funds that can securely run between the 
two networks (or indeed, on the % losses should an attack 
from the validators succeed). 

As such we believe it not unrealistic to place a reason- 
ably secure Bitcoin interoperability “virtual parachain” 
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between the two networks, though nonetheless a substan- 


(funded from fees coll m side) paid tial effort with an uncertain timeline and quite possibly 
requiring the cooperation of the stakeholders within that 
: i in i network. 


6. PROTOCOL IN DEPTH 


The protocol can be roughly broken down into three 
parts: the consensus mechanism, the parachain interface 
and interchain transaction routing. 


6.1. Relay-chain Operation. The relay-chain will 


likely be a chain broadly similar to Ethereum in that it 
is i 


E 1 o accounts here fulfils one pur- 


pose: to provide accounting for which identity possesses 
what amount of stake in the system.” There will be no- 
table differences, though: 


tions; following from the desir 
, it will not 


support public deployment of contracts. 
A CHT. ee ae 
See eee err ee 
, the rationale a p: accounting 


no longer holds. As such, will apply in 
all cases, allowing for more performance from any 
dynamic code execution that may need to be done 
and a simpler transaction format. 

° a i - 


In the event that the relay-chain has a VM and it be 
based around the EVM, it would have a number of mod- 
ifications to ensure maximal simplicity. It would likely 


have a number of built-in contracts (similar to those at 


addresses 1-4 in Ethereum) to allow for platform-specific 


duties to be managed including a consensus contract, a 


If not the EVM, then a aon [2] demgea) baal 


end is the most likely alternative; in this case the overa. 


structure would be similar, but there would E i 
ith Wasm being a viable target 


purpose languages rather than the immature 
and limited languages for the EVM. 
Other likely deviations from the present Ethereum pro- 
tocol are quite possible, for example a simplification of the - 


as proposed for the Serenity series of changes. 

It is possible, though unlikely, that a Serenity-like 
“pure” chain be deployed as the relay-chain, allowing for a 
particular contract to manage things like the staking token 
balances rather than making that a fundamental part of 
the chain’s protocol. At present, we feel it is unlikely this 
will offer a sufficiently great protocol simplification to be 
worth the additional complexity and uncertainty involved 
in developing it. 


TAs a means of representing the amount a given holder is responsible for the overall security of the system, these stake accounts will 
inevitably encode some economic value. However, it should be understood that since there is no intention that such values be used in 
any way for the purpose of exchanging for real-world goods and services, it should be accordingly noted that the tokens not be likened to 
currency and as such the relay-chain retain its nihilistic philosophy regarding applications. 
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There are a number of small pieces of functionality re- 
quired for administrating the consensus mechanism, val- 
idator set, validation mechanism and parachains. These 
could be implemented together under a monolithic proto- 
col. However, for reasons of auguring modularity, we de- 
scribe these as “contracts” of the relay-chain. This should 
be taken to mean that they are objects (in the sense of 
object-orientated programming) managed by the relay- 
chain’s consensus mechanism, but not necessarily that 
they are defined as programs in EVM-like opcodes, nor 
even that they be individually addressable through the 
account-system. 


6.2. StakingiContřäct. This contract maintains the val ™ 
“idator set. It manages: 


includes the machinery itself for the validation and canon- 
icalisation mechanism. 


6.2.1. Stake-token Liquidity. It is generally desirable to 


have as much of the total staking tokens as possible to be 
staked within the network maintenance operations since 
this directly ties the network security to the overall “mar- 
ket capitalisation” of the staking token. This can easily 
be incentivised through inflating the currency and hand- 
ing out the proceeds to those who participate as valida- 


tors. However, to do so presents a problem: if the token 


One answer to this is allowing a straight-forward de- 
rivative contract, securing fungible tokens on an underly- 
ing staked token. This is difficult to arrange in a trust- 


free manner. Furthermore, these derivative tokens can- 
not be treated equally for the same reason that differ- 
ent Eurozone government’s bonds are not fungible: there 
is a chance of the underlying asset failing and becoming 
worthless. With Eurozone governments, there could be a 
default. With validator-staked tokens, the validator may 
act maliciously and be punished. 
Keeping with our tenets, we elect for 
lution: | d. This would mean that 


of tokens will forcibly re= 


: : 
ae i pne this is imperfect from a security per- 


spective, it is unlikely to make a fundamental difference in 
the security of the network; 80% of the reparations possi- 
ble from bond-confiscations would still be able to be made 
compared to the “perfect case” of 100% staking. 

The ratio between staked and liquid tokens can be tar- 
geted fairly simply i 
Essentially, 


the minimum payout-rate that they would require to take 
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At the beginning of each session (sessions would 


happen regularly, the 


qh One possible algorithm 
or this would be to take those with the lowest offers who 
represent a stake no higher than the total stake targeted 
divided by the number of slots and no lower than a lower- 
bound of half that amount. If the slots cannot be filled, 


the lower bound could be repeatedly reduced by some fac- 
tor in order to satisfy. 


6.2.2. Nominating. It is possible to trustlessly nominate © 
ones staking tokens to an active validator, giving them 
the responsibility of validators duties. Nominating works 

. Each would-b 
nator is able to post an instruction to the staking contract 


represented by one or more validators. The dispersal al- 
gorithm oain aianei 
bonds. Nominators’ bonds become under the effective re- 


sponsibility of the validator an 
accordingly. 


6.2.3. "und aa Certain validator be- 
haviour results in a punitive reduction of their bond. If _ 
t 


exhaustive list of punishable validator misbehaviour in- 


cludes: 


Some cases of misbehaviour aD 
_tegrity (such as signing invalid parachain blocks and val- 
idating multiple sides of a fork) and as such result in ef- 


fective exile through the total reduction of the bond. In 
other, i s (e.g. inactivity in the consensus 
process) or cases where blame cannot be pretisely allot 
ted (being part of an ineffective group), 

. In the latter case, this 
works well with sub-group churn to ensure that malicious 
nodes suffer substantially more loss than the collaterally- 
damaged benevolent nodes. 


In some cases (e.g. multi-fork validation and invalid 


sub-block signing validators cannot themselves easily de- 
r since constant verification 


of each parachain block would be too arduous a task. Here 


it is necessary to enlist the support a 


haviour. The parties get a reward for reporting such ac- 

tivity; their term, “fishermen” stems from the unlikeliness 
of such a reward. 

Since these cases are typically very serious, we envi- 


sion that any rewards can easily be paid from the con- 
fiscated bond. In SGT ACO CSTE 
(i.e. reduction to nothing) with reallocation, rather than — 
pai This has the effect of 
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Sere atte seri hn hese 


y. This is mainly as a safety 


s involved could lead to ex 


mechanism: the 


In general, it is important that the reward is suffi- 
ciently large to make verification worthwhile for the net- 
work, yet not so large as to offset the costs of fronting a 
well-financed, well-orchestrated ”industrial-level” criminal 
hacking attack on some unlucky validator to force misbe- 
haviour. 


In this way, the amount claimed should generally be no. 


This can be combated either explicit]. 
through a o 


validator or implicitly by educating nominators that val- 
idators with little bonds deposited have no great incentive 


6.3. Parachain Registry. Each parachain is defined in 


this registry. It is a relatively simple database-like con- 
struct and 


Static information includes the chain index (a simple 


integer), along with the idati i a 


s consigned to putting forward a valid can- 
didate. An initial proof-of-concept would focus on placing 
the new validation algorithms into clients themselves, ef- 
fectively requiring a hard fork of the protocol each time an 
additional class of chain were added. Ultimately, though, 
it may be possible to specify the validation algorithm in 
a way both rigorous and efficient enough that clients are 
able to effectively work with new parachains without a 
hard-fork. One possible avenue to this would be to specify 
the parachain validation algorithm in a well-established, 
natively-compiled, platform-neutral language such as We- 
bAssembly. Additional research is necessary to determine 
whether this is truly feasible, however if so, it could bring 
with it the tremendous advantage of banishing hard-forks 
for good. 

Dynamic information includes aspects of the 


(described in section 6.6). 
The registry is able to have i 


Tirai 
"henna s; this could be managed 
internally but would more likely be placed in an external 
referendum contract in order to facilitate re-usage under 
more general governance components. The parameters to 
voting requirements (e.g. any quorum required, majority 
required) for registration of additional chains and other, 
less formal system upgrades will be set out in a “master 
constitution” but are likely to follow a fairly traditional 
path, at least initially. The precise formulation is out of 
scope for the present work, but e.g. a two thirds super- 
majority to pass with more than one third of total system 
stake voting positively may be a sensible starting point. 
Additional operations include the 


moval of parachains. Suspension would hopefully never 
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happen, however it is designed to be a safeguard least 
there be some intractable problem in a parachain’s vali- 
dation system. The most obvious instance where it might 
be needed is a consensus-critical difference between im- 
plementations leading validators to be unable to agree on 
validity or blocks. Validators would be encouraged to use 
multiple client implementations in order that they are able 
to spot such a problem prior to bond confiscation. 


The grace period would likely be of 

and is likely to be set out on a per- 
chain basis in the parachain registry in order that different 
parachains can enjoy different grace periods according to 
their need. 


the order of 


6.4. i 
to the process of 


Sealing refers, in essence, 
; that is, 


e reee a aaa 
sealing is effectively a synonym for mining. In our case, 


it involves 


e mechanics of the underlying 


: e wi 
instead describe it using a primitive which assumes a 
consensus-creating state-machine. Ultimately we expect 
to be inspired by a number of promising BFT consensus 
algorithms in the core; Tangaora [9] (a BFT variant of 
Raft [16]), Tendermint [11] and HoneyBadgerBFT [14]. 


. We assume that once 


i 
the participants to it. We also assume eo 
within the protocol can be generally reduced to a small 


e 


The proof, which takes the form of our signed state- 
ments, is placed in the relay-chain block’s header together 


nt: parachains are not sepa- 
rately “committed” by their sub-groups and then collated 
later. This results in a more complex process fi 
chain, but allows us to 
sensus in a single stage, g 
for quite complex data-availability requirements which are 
helpful for the routing process below. 


8Existing PoS-based BFT consensus schemes such as Tendermint BFT and the original Slasher fulfill these assertions. 


POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK 


The state of each participant’s consensus machine may 
be modelled as a simple (2-dimensional) table. Each par- 
ticipant (validator) has a set of information, in the form 
of signed-statements (“votes”) from other participants, re- 
garding each parachain block candidate as well the relay- 
chain block candidate. The set of information is two pieces 
of data: 


Availability: does this validator have egress 
transaction-post information from this block so 
they are able to properly validate parachain can- 
didates on the following block? They may vote 
either 1(known) or 0 (not yet known). Once they 
vote 1, they are committed to voting similarly for 
the rest of this process. Later votes that do not 
respect this are grounds for punishment. 

Validity: is the parachain block valid and is all 
externally-referenced data (e.g. transactions) 
available? This is only relevant for validators as- 
signed to the parachain on which they are voting. 
They may vote either 1 (valid), -1 (invalid) or 0 
(not yet known). Once they vote non-zero, they 
are committed to voting this way for the rest of 
the process. Later votes that do not respect this 
are grounds for punishment. 


All validators 
mitted, qualified by the rules above. The progression of 
consensus may be modelled as multiple standard BFT con- 
sensus algorithms over each parachain happening in par- 
allel. Since these are potentially thwarted by a relatively 
small minority of malicious actors being concentrated in 


submit votes; votes may be resub- 


a single parachain group, the overall consensus exists to 
establish a backstop, limiting the worst-case scenario from 
deadlock to merely one or more void parachain blocks (and 
a round of punishment for those responsible). 

The basic rules for validity of the individual blocks 
(that allow the total set of validators as a whole to come to 
consensus on it becoming the unique parachain candidate 
to be referenced from the canonical relay): 


e must have at least two thirds of its validators vot- 
ing positively and none voting negatively; 

e must have over one third validators voting posi- 
tively to the availability of egress queue informa- 
tion. 


If there is at least one positive and at least one nega- 
tive vote on validity, an exceptional condition is created 
and the whole set of validators must vote to determine 
if there are malicious parties or if there is an accidental 
fork. Aside from valid and invalid, a third kind of votes 
are allowed, equivalent to voting for both, meaning that 
the node has conflicting opinions. This could be due to the 
node’s owner running multiple implementations which do 
not agree, indicating a possible ambiguity in the protocol. 

After all votes are counted from the full validator set, if 
the losing opinion has at least some small proportion (to 
be parameterised; at most half, perhaps significantly less) 
of the votes of the winning opinion, then it is assumed to 
be an accidental parachain fork and the parachain is au- 
tomatically suspended from the consensus process. Oth- 
erwise, we assume it is a malicious act and punish the 
minority who were voting for the dissenting opinion. 


DRAFT 1 12 


The conclusion is a set of signatures demonstrating 
canonicality. The relay-chain block may then be sealed 
and the process of sealing the next block begun. 


6.5. Improvements for Sealing Relay Blocks. While 
this sealing method gives strong guarantees over the sys- 
tem’s operation, it does not scale out particularly well 
since every parachain’s key information must have its 
availability guaranteed by over one-third of all validators. 
This means that every validator’s responsibility footprint 
grows as more chains are added. 

While data availability within open consensus networks 
is essentially an unsolved problem, there are ways of miti- 
gating the overhead placed on validator nodes. One simple 
solution is to realise that while validators must shoulder 
the responsibility for data availability, they need not actu- 
ally store, communicate or replicate the data themselves. 
Secondary data silos, possibly related to (or even the very 
same) collators who compile this data, may manage the 
task of guaranteeing availability with the validators pro- 
viding a portion of their interest/income in payment. 

However, while this might buy some intermediate scal- 
ability, it still doesn’t help the underlying problem; since 
adding more chains will in general require additional val- 
idators, the ongoing network resource consumption (par- 
ticularly in terms of bandwidth) grows with the square of 
the chains, an untenable property in the long-term. 

Ultimately, we are likely to keep bashing our heads 
against the fundamental limitation which states that for 
a consensus network to be considered available safe, the 
ongoing bandwidth requirements are of the order of total 
validators times total input information. This is due to 
the inability of an untrusted network to properly distrib- 
ute the task of data storage across many nodes, which sits 
apart from the eminently distributable task of processing. 


6.5.1. Introd ncy. One means of softening this 
rule is to relax the notion of immediacy. By requir- 
ing 33%+1 validators voting for availability only eventu- 
ally, and not immediately, we can better utilise exponen- 
tial data propagation and help even out peaks in data- 


interchange. A reasonable equality (though unproven) 
may be: 
(1) latency = participants x chains 


Under the current model, the size of the system scales 
with the number of chains to ensure that processing is 
distributed; since each chain will require at least one val- 
idator and we fix the availability attestation to a constant 
proportion of validators, then participants similarly grows 
with the number of chains. We end up with: 


(2) latency = size” 


Meaning that as the system grows, the bandwidth re- 
quired and latency until availability is known across the 
network, which might also be characterised as the number 
of blocks before finality, increases with its square. This is 
a substantial growth factor and may turn out to be a no- 
table road blocker and force us into “non-flat” paradigms 
such as composing several “Polkadotes” into a hierarchy 
for multi-level routing of posts through a tree of relay- 
chains. 
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6.5.2. Public Participation. One more possible direction 
is to enlist public participation in the process through a 
Similar to the fishermen, there 
could be e i 
Their task is to find one who appears un- 
able to demonstrate such availability. In doing so they 
can lodge a micro-complaint to other validators. PoW or 
a staked bond may be used to mitigate the sybil attack 
which would render the system largely useless. 


6.5.3. oe ER route would be to 


” These would be bonded just as with the nor- 
mal validators, and may even be taken from the same set 
(though if so, they would be chosen over a long-term pe- 
riod, at least per session). Unlike normal validators, they 
but rather would 


This has the advantage of relaxing the equivalence be- 


tween participants and chains. Essentially, chains can 


the participants, and specifically those taking part in data- 


availability testament, can remain at the least sub-linear 


6.5.4. Collator Preferences. One important aspect of this 
system is to ensure that there is a healthy selection of 
creating the blocks in any given parachain, If a 


sin 


become more feasible since the likelihood of the lack of | 


One option is to a in 


riety of collators. In the first instance, we would require 


as part of the consensus mechanism that validators favour 
parachain block candidates determined to be “heavier”. 


done throug 


Similarly, we must ieee ae to attempt to 
suggest the weightiest block they can find—this could be 


To ensure that collators are 


iN £s the winning 
candidate in consensus, we make the specific weight of a 


parachain block candidate determinate on 
tion connected with each collator. For example, taking 
the XOR distance measure between the collator’s address 


and some cryptographically-secure pseudorandom number 
determined close to the point of the block being created 
(a notional “winning ticket”). This effectively gives each 
collator (or, more specifically, each collator’s address) a 
random chance of their candidate block “winning” over 
all others. 


ss. This may be as simple as requiring them 
to have a baseline amount of funds in the address. A more 
elegant approach would be to weight the proximity to the 
winning ticket with the amount of funds parked at the 


address in question. While modelling ha 
it is quite os that this mechanism enables eve 


6.5.5. Overweight Blocks. If a 


hey may 


. This is a problem since a validator group coul 
reasonably form a block which takes a very long time to 
execute unless i 
, e.g. factoring a large 
prime. 
ge in getting their own 
candidates accepted as long as the others were busy pro- 
cessing the old block. We call these blocks overweight. 
Protection against validators submitting and validat- 
ing these blocks largely falls under the same guise as for 
invalid blocks, though with an additional caveat: Since 
the time taken to execute a block (and thus its status as 
overweight) is subjective, the final outcome of a vote on 


misbehaviour will fall into essentially three camps. One 
possibility is that the block is dete ESEN 
in this case more than two-thirds declare that they could — 


execute the block within some limit (e.g. 50% of the to- 
tal time allowed between blocks). Another is that 
block is definitely overweight—this would be if 


t 


One final possibility is a 
n between validators. In this case, we may 


To ensure validators can predict when they may be 


proposing an overweight block, it may be sensible to re- 


. Over a sufficient period of time, 


this should allow them t 
all 


6.5.6 . One issue remains for valida- 
tors: unlike with PoW networks, 

bl P. 
actions in it. Malicious collators can feed invalid or over- 
weight blocks to validators causing them grief (wasting 
their resources) and exacting a potentially substantial op- 
portunity cost. 


To mitigate this, we propose a simple strategy on the 
part of validators aT vo 


with funds; i 
ALMATY, such CE BED 
dered in priority by a combination (e.g. multiplication) of | 


fully proposed in the past (not to mention any previous 
punishments), 

as discussed previously. The cap should be the same 
as the punitive damages paid to the validator in the case 
of them sending an invalid block. 


To disincentivise collators from sending invalid or over- 


weight block candidates to validators, oF 
ing block alleging misbehaviour with the effect of transfer- 


This type of trans- 


action fro to ensure the collator cannot 


. The amount of 
funds transferred as damages is a dynamic parameter yet 
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to be modelled but will likely be a proportion of the val- 
idator block reward to reflect the level of grief caused. To 
prevent malicious validators arbitrarily confiscating colla- 
tors’ funds, the collator may appeal the validator’s deci- 
sion with a jury of randomly chosen validators in return 
for placing a small deposit. If they find in the valida- 
tor’s favour, the deposit is consumed by them. If not, the 
deposit is returned and the validator is fined (since the 
validator is in a much more vaulted position, the fine will 
likely be rather hefty). 


6.6. Interchain ‘Transaction Routing. Interchain 
transaction routing is one of the essential maintenance 
tasks of the relay-chain and its validators. This is the 
logic which governs how a posted transaction (often short- 
ened to simply “post”) gets from being a desired output 
from one source parachain to being a non-negotiable in- 
put of another destination parachain without any trust 
requirements. 

We choose the wording above carefully; notably we 
don’t require there to have been a transaction in the source 
parachain to have explicitly sanctioned this post. The only 
constraints we place upon our model is that parachains 
must provide, packaged as a part of their overall block 
processing output, the posts which are the result of the 
block’s execution. 

These posts are structured as several FIFO queues; the 
number of lists is known as the routing base and may be 
around 16. Notably, this number represents the quantity 
of parachains we can support without having to resort to 
multi-phase routing. Initially, Polkadot will support this 
kind of direct routing, however we will outline one possible 
multi-phase routing process (“hyper-routing” ) as a means 
of scaling out well past the initial set of parachains. 

We assume that all participants know the sub- 
groupings for next two blocks n, n +1. In summary, the 
routing system follows these stages: 


e Collators: Contact members of Validators|n][S] 
e Collatorg: FOR EACH subgroup s: ensure at 
least 1 member of Validators|n][s] in contact 
e Collatorg: FOR EACH subgroup s: 
egress|n — 1][s][.$] is available (all incoming post 

data to ‘S‘ from last block) 

e Collatorgs: Compose block candidate b for S: 
(b.header, b.ext, b.proof, b.receipt, b.egress) 

e Collators: Send proof information 
proof |S] = (b.header, b.ext, b.proof, b.receipt) to 
Validator s[n][5] 

e Collators: Ensure external transaction data b.ext 
is made available to other collators and validators 

e Collators: FOR ACH subgroup s: 
Send egress [s] 
(b.header, b.receipt, b.egress|s]) to the re- 
ceiving sub-group’s members of next block 
Validators[n + 1][s] 

e Validatory: Pre-connect all same-set members 
for next block: let N = Chain|n + 1][V]; connect 
all validators v such that Chain[n + 1][v] = N 

e Validatory: Collate all data ingress for this 
block: FOR EACH subgroup s: Retrieve 
egress[n — 1][s][Chain|n][V]], get from other val- 
idators v such that Chain[n][v] = Chain[n][V]. 


assume 


information egress{n}[S] = 
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Possibly going via randomly selected other val- 
idators for proof of attempt. 

e Validatory: Accept candidate proofs for this 
block proof (Chain|n][V]]. Vote block validity 

e Validatory: Accept candidate egress data for 
next block: FOR EACH subgroup s, accept 
egress|n][s][N]. Vote block egress availability; re- 
publish among interested validators v such that 
Chain[n + 1][v] = Chain|[n + 1][V]. 

e Validatory: UNTIL CONSENSUS 


Where: egress[n][from]|to] is the current egress queue 
information for posts going from parachain ‘from‘, to 
parachain ‘to’ in block number ‘n‘. Collatorg is a col- 
lator for parachain S. Validators{n][s] is the set of val- 
idators for parachain s at block number n. Conversely, 
Chain|n][v] is the parachain to which validator v is as- 
signed on block number n. block.egress|to] is the egress 
queue of posts from some parachain block block whose 
destination parachain is to. 

Since collators collect (transaction) fees based upon 
their blocks becoming canonical they are incentivised to 
ensure that for each next-block destination, the subgroup’s 
members are informed of the egress queue from the present 
block. Validators are incentivised only to form a consen- 
sus on a (parachain) block, as such they care little about 
which collator’s block ultimately becomes canonical. In 
principle, a validator could form an allegiance with a col- 
lator and conspire to reduce the chances of other collators’ 
blocks becoming canonical, however this is both difficult 
to arrange due to the random selection of validators for 
parachains and could be defended against with a reduc- 
tion in fees payable for parachain blocks which hold up 
the consensus process. 


6.6.1. External Data Availability. Ensuring a parachain’s 
external data is actually available is a perennial issue with 
decentralised systems aiming to distribute workload across 
the network. At the heart of the issue is the availability 
problem which states that since it is neither possible to 
make a non-interactive proof of availability nor any sort 
of proof of non-availability, for a BFT system to properly 
validate any transition whose correctness relies upon the 
availability of some external data, the maximum number 
of acceptably Byzantine nodes, plus one, of the system 
must attest to the data being available. 

For a system to scale out properly, like Polkadot, this 
invites a problem: if a constant proportion of validators 
must attest to the availability of the data, and assuming 
that validators will want to actually store the data be- 
fore asserting it is available, then how do we avoid the 
problem of the bandwidth/storage requirements increas- 
ing with the system size (and therefore number of valida- 
tors)? One possible answer would be to have a separate set 
of validators (availability guarantors), whose order grows 
sublinearly with the size of Polkadot as a whole. This is 
described in 6.5.3. 

We also have a secondary trick. As a group, colla- 
tors have an intrinsic incentive to ensure that all data is 
available for their chosen parachain since without it they 
are unable to author further blocks from which they can 
collect transaction fees. Collators also form a group, mem- 
bership of which is varied (due to the random nature of 
parachain validator groups) non-trivial to enter and easy 
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(perhaps of the last few thou- 


sand bloc 
th 


or 
(direct re- 


fusal to provide the data counts as a bond-confiscating of- 
fence, therefore the misbehaving validator will likely just 
drop the connection) i 

to run the same test. In the latter case, the collator’s bond 
is returned. 


e. We assume strong, 
probably CSPR?, sub-block ordering to achieve a deter- 
ministic operation that offers no favouritism between any 


parachain block pairing. 

a ’S 
i . This has two main purposes: 
firstly, it means that 


idators and collators are able to process following blocks 
without having to source the queue’s data specially. 


used to demonstrate fidelity of the collator’s operation in 
the parachain block’s proof. 


6.6.3. Critique. One min 
mechanism is the 


(6B particular RO While this ties up the target’s 
ingress queue at once, GPE cES ITE TORTS SOS 


k. 

Operating normally, with a set of well-synchronised and 
non-malicious collators and validators, for N parachains, 
N x M total validators and L collators per parachain, we 
can break down the total data pathways per block to: 

Validator: M—1+L+L: M-—1 for the other validators 
in the parachain set, L for each collator providing a can- 
didate parachain block and a second L for each collator 
of the next block requiring the egress payloads of the pre- 
vious block. (The latter is actually more like worst-case 


ting to this basic 
This is where all 


%cryptographically secure pseudo-random 
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operation since it is likely that collators will share such 
data.) 

Collator: M +kN: M for a connection to each relevant 
parachain block validator, kN for seeding the egress pay- 
loads to some subset of each parachain validator group for 
the next block (and possibly som 

As such, the 
While this is 
reasonable, as the system scales into hundreds or thou- 
sands of parachains, some communication latency may be 
absorbed in exchange for a lower complexity growth rate. 
In this case, a multi-phase routing algorithm may be used 
in order to reduce the number of instantaneous pathways 
at a cost of introducing storage buffers and latency. 


6.6.4. j Hyper-cube routing is a mech- 
anism which can mostly be build as an extension to the 
basic routing mechanism described above. Essentially, 


rather than growing the node connectivity with the num- 


ber of parachains and _ nodes, we 


Routing itself is deterministic and simple. We begin by 
limiting the number of bins in the ingress/egress queues; 
rather than being the total number of parachains, they 
are the routing-base (b) . This will be fixed as the number 
of parachains changes, with the routing-exponent (e) in- 
stead being raised. Under this model, our message volume 
grows with O(b°), with the pathways remaining constant 
and the latency (or number of blocks required for delivery) 
with O(e). 

Our model of routing is a hypercube of e dimensions, 
with each side of the cube having b possible locations. 
Each block, we route messages along a single axis. We 
alternate the axis in a round-robin fashion, thus guaran- 
teeing worst-case delivery time of e blocks. 

As part of the parachain processing, foreign-bound 
messages found in the ingress queue are routed imme- 
diately to the appropriate egress queue’s bin, given the 
current block number (and thus routing dimension). This 
process necessitates additional data transfer for each hop 
on the delivery route, however this is a problem itself 
which may be mitigated by using some alternative means 
of data payload delivery and including only a reference, 
rather than the full payload of the post in the post-trie. 

An example of such a hyper-cube routing for a system 
with 4 parachains, b = 2 and e = 2 might be: 

Phase 0, on each message M: 

e subo: if Maest € {2,3} then sendTo(2) else keep 
e subi: if Maest € {2,3} then sendTo(3) else keep 
e subs: if Maest € {0,1} then sendTo(0) else keep 
e subs: if Maest € {0,1} then sendTo(1) else keep 
Phase 1, on each message M: 
e subo: if Maest € {1,3} then sendTo(1) else keep 
e subi: if Maest € {0,2} then sendTo(0) else keep 
e sub2: if Maest € {1,3} then sendTo(3) else keep 
e subs: if Maest € {0,2} then sendTo(2) else keep 

The two dimensions here are easy to see as the first 
two bits of the destination index; for the first block, the 
higher-order bit alone is used. The second block deals 
with the low-order bit. Once both happen (in arbitrary 
order) then the post will be routed. 
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6.6.5. Bn cece a WE 
proposa ed total of i i 


Each block, rather than 


there being a partitioning of validators 


among parachains, instead for each parachain sub-group, 


z 1S Wou. 


lead to the invariant that 


While this can- 
not be used to gain absolute guarantees on availability 
(a single validator will occasionally drop offline, even if 
benevolent), it can nonetheless optimise the general case. 


This approach is not without a 


pie te Furthermore the number of valida- 
tors, being tied to the square of the number of parachains, 
would start initially very small and eventually grow far 
too fast, becoming untenable after around 50 parachains. 
None of these are fundamental problems. In the first case, 
reorganisation of validator sets is something that must be 
done regularly anyway. Regarding the size of the validator 
set, when too small, multiple validators may be assigned 
to the same parachain, applying an integer factor to the 
overall total of validators. A multi-phase routing mecha- 
nism such as Hypercube Routing, discussed in 6.6.4 would 
alleviate the requirement for large number of validators 
when there is a large number of chains. 


6.7. Parachain Validation. A validator’s main purpose 
is to testify, as a well-bonded actor, that a parachain’s 


o he process itself is fairly simple. 
Once the validator sealed the previous block they are free 
to begin working to provide a candidate parachain block 
candidate for the next round of consensus. 

Initially, the validator 


Gahaa (ceseribed next) or ons 
of its co-validators. The parachain block candidate data 


includes the block’s header, 


a Ba aime (for Ethereum and Bit- 
coin, such data would be referred to as transactions, how- 


ever in principle they may include arbitrary data struc- 
tures for arbitrar = 
y (for Ethereum 


this would be the various state/storage trie nodes re- 
quired to execute each transaction). Experimental evi- 
dence shows this full dataset for a recent Ethereum block 
to be at the most a few hundred KiB. 

Simultaneously, if not yet done, the validator will be 


el 


Once the validator has received such a candidate block, 
they then . The validation process is con- 
a 


consensus-sensitive software module that must be written 
for any implementation of Polkadot (though in principle 
a library with a C ABI could enable a single library to 
be shared between implementations with the appropriate 


ey 
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reduction in safety coming from having only a single “ref- 
erence” implementation). 


The process takes the previous block’s header and ver- 
block in which its hash should be recorded. Once the par- 
ent header’s validity is ascertained, the specific parachain 
class’s validation function may be called. This is a sin- 
gle function accepting a number of data fields (roughly 
those given previously) and returning a simple Boolean 
proclaiming the validity of the block. 
the parent block (e.g. parent_hash, number). Following 


this, they will 


or an Ethereum-like chain this amounts to populating a 
trie database with the nodes that will be needed for the 
full execution of transactions. Other chain types may have 
other preparatory mechanisms. 

Once done, 

r whatever the external data represents) will be 
enacted, i (A 
sensible default might be to require all ingress posts be 
processed before external transactions be serviced, how- 
ever this should be for the parachain’s logic to decide.) 
Through this enactment, 


the collator’s candidate. Finally, the 
h 


6.7.1. Parachain collators are un- _ 


on the present-day blockchain networks. They are specific — 


to a particular parachain. In order to operate they must 


The precise meaning of “fully synchronised” will de- 
pend on the class of parachain, though will always in- 
clude the present state of the parachain’s ingress queue. 
In Ethereum’s case it also involves at least maintaining 
a Merkle-tree database of the last few blocks, but might 
also include various other data structures including Bloom 
filters for account existence, familial information, logging 
outputs and reverse lookup tables for block number. 

In addition to keeping the two chains synchronised, it 


t 


“from the public network. With the queue and chain, it is 


sen at each block ( since the relay- 
chain is synchronised aaa together with the 
various ancillary information such as proof-of-validity, via 
the peer network. 

For its trouble, it/collects all fees relating to the trans- 
actions it includes Various economics float around this 
arrangement. In a heavily competitive market where there 
is a surplus of collators, it is possible that the transaction 
fees be shared with the parachain validators to incentivise 
the inclusion of a particular collator’s block. Similarly, 
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some collators may even raise the required fees that need 
to be paid in order to make the block more attractive to 


validators. In this case, 


6.8. Networking. Networking on traditional blockchains 


like Ethereum and Bitcoin has rather simple requirements. 


All transactions and blocks are broadcast in a simple undi- 


ynchronisation is more involved, especially 
with Ethereum but in reality this logic was contained in 
the peer strategy rather than the protocol itself which re- 
solved around a few request and answer message types. 

While Ethereum made progress on current protocol of- 
ferings with the devp2p protocol, which allowed for many 
subprotocols to be multiplexed over a single peer connec- 
tion and thus have the same peer overlay support many 
p2p protocols simultaneously, the Ethereum portion of 
the protocol still remained relatively simple and the p2p 
protocol as a while remains unfinished with important 
functionality missing such as QoS support. Sadly, a de- 
sire to create a more ubiquitous “web 3” protocol largely 
failed, with the only projects using it being those explicitly 
funded from the Ethereum crowd-sale. 

The requirements for Polkadot are rather more sub- 
stantial. Rather then a wholly uniform network, Polkadot 
has several types of participants each with different re- 
quirements over their peer makeup and several network 
“avenues” whose participants will tend to converse about 
particular data. This means a substantially more struc- 
tured network overlay—and a protocol supporting that— 
will likely be necessary. Furthermore, extensibility to fa- 
cilitate future additions such as new kinds of “chain” may 
themselves require a novel overlay structure. 

While an in-depth discussion of how the networking 
protocol may look is outside of the scope of this docu- 
ment, some requirements analysis is reasonable. We can 
roughly break down our network participants into two sets 
(relay-chain, parachains) each of three subsets. We can 
also state that each of the parachain participants are only 
interested in conversing between themselves as opposed to 
participants in other parachains: 

e Relay-chain participants: 
e Validators: P, split into subsets P[s] for each 
parachain 
« Availability Guarantors®*A) (this may be repre- 
sented by Validators in the basic form of the pro- 


tocol) 
e Relay-chain clients: M (note members of each 
parachain set will also tend to be members of M) 


In general we name particular classes of communication 
will tend to take place between members of these sets: 


eP|A <> P| A: 


achieve consensus 


e P[s] <-> CĪs] | 


PIs]: 


of that parachain to discover and share block can- 


e A <-> PIs] | C | A: Each availability guarantor 


Once they have it, the 


e P[s] <-> A | Pl[s']: a ee ot ee 


e F[s] <-> P: When reporting, fishermen may place 
e M <->M | P | A: General relay-chain clients dis 


-disburse data from the full clients. — 

To ensure an efficient transport mechanism, a “flat” 
overlay network—like Ethereum’s devp2p—where each 
node does not (non-arbitrarily) differentiate fitness of its 
peers is unlikely to be suitable. i 


ime. 

The precise strategy of peer make-up will be differ- 
ent for each class of participant: for a properly scaled-out 
multi-chain, collators will either need to be continuously 
reconnecting to the accordingly elected validators, or will 
need on-going agreements with a subset of the validators 
to ensure they are not disconnected during the vast ma- 
jority of the time that they are useless for that valida- 
tor. Collators will also naturally attempt to maintain one 
or more stable connections into the availability guarantor 
set to ensure swift propagation of their consensus-sensitive 
data. 

Availability guarantors will mostly aim to maintain a 
stable connection to each other and to validators (for con- 
sensus and the consensus-critical parachain data to which 
they attest), as well as to some collators (for the parachain 
data) and some fishermen and full clients (for dispersing 
information). Validators will tend to look for other val- 
idators, especially those in the same sub-group and any 
collators that can supply them with parachain block can- 
didates. 

Fishermen, as well as general relay-chain and parachain 
clients will generally aim to keep a connection open to a 
validator or guarantor, but plenty of other nodes similar 
to themselves otherwise. Parachain light clients will simi- 
larly aim to be connected to a full client of the parachain, 
if not just other parachain light-clients. 


6.8.1. The Problem of Peer Churn. In the basic proto- 
col proposal, each of these subsets constantly alter ran- 
domly with each block as the validators assigned to verify 
the parachain transitions are randomly elected. This can 
be a problem should disparate (non-peer) nodes need to 
pass data between each other. One must either rely on 
a fairly-distributed and well-connected peer network to 
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ensure that the hop-distance (and therefore worst-case la- 
tency) only grows with the logarithm of the network size 
(a Kademlia-like protocol [13] may help here), or one must 
introduce longer block times to allow the necessary con- 
nection negotiation to take place to keep a peer-set that 
reflects the node’s current communication needs. 

Neither of these are great solutions: long block times 
being forced upon the network may render it useless for 
particular applications and chains. Even a perfectly fair 
and connected network will result in substantial wastage 
of bandwidth as it scales due to uninterested nodes having 
to forward data useless to them. 

While both directions may form part of the solution, 
a reasonable optimisation to help minimise latency would 
be to 


-g. in groups of 15, which at a 4 second 
block time would mean altering connections only once per 
minute) 

ion, e.g. changing by one member at a time (e.g. if there 
are 15 validators assigned to each parachain, then on av- 
erage it would be a full minute between completely unique 
sets). By limiting the amount of peer churn, and ensur- 
ing that advantageous peer connections are made well in 
advance through the partial predictability of parachain 
sets, we can help ensure each node keep a permanently 
serendipitous selection of peers. 


6.8.2. Path to an Effective Network Protocol. Likely the 
most effective and reasonable development effort will fo- 
cus on utilising a pre-existing protocol rather than rolling 
our own. Several peer-to-peer base protocols exist that 
we may use or augment including Ethereum’s own devp2p 
[22], IPFS’s libp2p [1] and GNU’s GNUnet [4]. A full re- 
view of these protocols and their relevance for building a 
modular peer network supporting certain structural guar- 
antees, dynamic peer steering and extensible sub-protocols 
is well beyond the scope of this document but will be an 
important step in the implementation of Polkadot. 


7. PRACTICALITIES OF THE PROTOCOL 


7.1. Interchain Transaction Payment. While a great 
amount of freedom and simplicity is gained through drop- 
ping the need for a holistic computation resource account- 
ing framework like Ethereum’s gas, this does raise an im- 


portant question: wi 


tion? While 


This is a . Since chains 
are free to attach arbitrary semantics on to the incoming 


transaction- 
n a similar vein to the 


model espoused by Ethereum Serenity, we can imagine 
a “break-in” contract within a parachain which allows a 
validator to be guaranteed payment in exchange for the 
provision of a particular volume of processing resources. 
These resources may be measured in something like gas, 
but could also be some entirely novel model such as sub- 
jective time-to-execute or a Bitcoin-like flat-fee model. 
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On its own this isn’t so useful since we cannot read- 
ily assume that the off-chain caller has available to them 
whatever value mechanism is recognised by the break-in 
contract. However, we can imagine a secondary “break- 
out” contract in the source chain. The two contracts to- 
gether would form a bridge, recognising each other and 
providing value-equivalence. (Staking-tokens, available to 
each, could be used to settle up the balance-of-payments. ) 
Calling into another such chain would mean proxying 
through this bridge, which would provide the means of 
negotiating the value transfer between chains in order to 
pay for the computation resources required on the desti- 
nation parachain. 


7.2. Additional Chains. While the addition of a 
parachain is a relatively cheap operation, it is not free. 


While the issue of a smaller coer- 


cion cost for attacking a parachain is mitigated through 
fishermen, the 


derlying consensus method. Furthermore caghpanachainy 


brings with it the potential to grief validators with an- 
over-burdensome validation algorithm. 

As such, there will be some “price” that validators 
and/or the stake-holding community will extract for the 
addition of a new parachain. This market for chains will 
possibly see the addition of either: 


e Chains that likely have zero net contribution pay- 
ing (in terms of locking up or burning staking to- 
kens) rt (e.g. consortium chains, 


Doge-chains, app-specific ainai 
e 
a (e.g. confidentiality, internal scal- 


ability, service tie-ins). 


Essentially, tiD o 


It is envisioned that new chains added will have a very 
short notice period for removal, allowing for new chains to 
be experimented with without any risk of compromising 
the medium or long-term value proposition. 


8. CONCLUSION 


We have outlined a direction one may take to author a 
scalable, heterogeneous multi-chain protocol with the po- 
tential to be backwards compatible to certain, pre-existing 
blockchain networks. Under such a protocol, participants 
work in enlightened self-interest to create an overall sys- 
tem which can be extended in an exceptionally free man- 
ner and without the typical cost for existing users that 
comes from a standard blockchain design. We have given 
a rough outline of the architecture it would take including 
the nature of the participants, their economic incentives 
and the processes under which they must engage. We have 
identified a basic design and discussed its strengths and 
limitations; accordingly we have further directions which 
may ease those limitations and yield further ground to- 
wards a fully scalable blockchain solution. 
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8.1. Missing Material and Open Questions. Net- 
work forking is always a possibility from divergent im- 
plementations of the protocol. The recovery from such an 
exceptional condition was not discussed. Given the net- 
work will necessarily have a non-zero period of finalisation, 
it should not be a large issue to recover from the relay- 
chain forking, however will require careful integration into 
the consensus protocol. 

Bond-confiscation and conversely reward provision has 
not been deeply explored. At present we assume rewards 
are provided under a winner-takes-all basis: this may not 
give the best incentivisation model for fishermen. A short- 
period commit-reveal process would allow many fishermen 
to claim the prize giving a fairer distribution of rewards, 
however the process could lead to additional latency in the 
discovery of misbehaviour. 
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APPENDIX A. FUNCTIONAL COMPONENTS 


Seen from a high-level, the Parity Polkadot Platform stack has a number of functional components and any develop- 
ment of it will require a substantial amount of research and development prior to it being completed. 

Some components are dependent on others existing, others are independent. Some are very important for the platform 
to function properly, others are nice-to-haves. Some are of indeterminate complexity and have not yet been deemed 


feasible, others are relatively straight-forward. 


Here we’ll try to list as many such components as possible along with where they would fit into our development 


roadmap. 


Networking subsystem: This is the means by which a peer network is formed and maintained. Simple alterations 
of existing peer-to-peer networking libraries (devp2p most likely) will be sufficient for an initial system. However, 
additional research and development will be necessary to ensure that as the network grows, the network topology 
becomes increasingly structured allowing for optimal data logistics. For the final deployment, adaptations of 
libp2p, devp2p and GNUnet should be first considered. If requirements are not likely to be met then a new 


protocol should be considered. 


Consensus mechanism: Proof-of-authority consensus mechanism supporting rich validator statements and al- 
lowing multiple independent items to be agreed upon under a single series based upon subjective reception of 
the partial set of validator statements. The mechanism should allow the proof of misbehaviour for the dismissal 
of malicious validators but need not involve any staking mechanism. A substantial amount of research and 
prototyping will precede the development of this component. 

Proof-of-stake chain: Extending the consensus mechanism into proof-of-stake territory; this module includes 
staking tokens, managing entry and exit from the validator pool, a market mechanism for determining validator 
rewards, finalising the approval-voting nomination mechanism and managing bond-confiscation and dismissal. 
It includes a substantial amount of research and prototyping prior to final development. 
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Parachain implementation: A first parachain implementation, likely to be based heavily on an existing blockchain 
protocol such as Bitcoin or (more likely, since it provides for rich transactions) Ethereum. This will include an 
integration with the proof-of-stake chain, allowing the parachain to gain consensus without its own internal 
consensus mechanism. 

Transaction processing subsystem: An evolution of the parachain and relay-chain, this will allow for trans- 
actions to be sent, received and propagated. It includes the designs of transaction queuing and optimised 
transaction routing on the network layer. 

Transaction-routing subsystem: This introduces more specifics into the relay-chain’s behaviour. Initially, 
adding transactability into parachains will be needed. Following that, with two parachains hard-coded into 
the relay-chain, it will include the management of the ingress/egress queues. Eventually this will develop along 
with the network protocol into a means of directed transaction propagation, ensuring independent parachain 
collators are not overly exposed to transactions that are not of interest. 

Relay chain: This is the final stage of the relay-chain, allowing the dynamic addition, removal and emergency 
pausing of parachains, the reporting of bad behaviour and includes implementation of the “fisherman” function- 
ality. 

Independent collators: This is the delivery of an alternative chain-specific collator functionality. It includes 
proof creation (for collators), parachain misbehaviour detection (for fishermen) and the validation function (for 
validators). It also includes any additional networking required to allow the two to discover and communicate. 

Network dynamics modelling and research: The overall dynamics of this protocol should be researched thor- 
oughly. This can happen both through offline network modelling and through empirical evidence through simu- 
lated nodes. The latter is dependent on the relay-chain and will include the development of a structured logging 
protocol allowing nodes to submit detailed reports on their actions to a central hub for collation. 

Network intelligence: As a complex decentralised multi-party network, a network intelligence hub similar to 
http://ethstats.net is needed to monitor the life-signs of the network as a whole and flag potentially disruptive 
behaviour. Structured logging should be used to generate and visualise this data in real-time for maximum 
efficiency. It is dependent on the relay-chain being in a reasonably complete state. 

Information publication platform: This is a mechanism for publishing data relating to the blockchain, and 
effectively means a decentralised content-discovery network. Initially it can be handled by basic peer-to-peer 
lookups but for deployment will likely require a more structured and robust solution since availability will become 
a critical piece of information. IPF'S integration may be the most sensible means of achieving these goals. 

Javascript interaction bindings: The main means of interacting with the network will likely follow the example 
of Ethereum and as such high-quality Javascript bindings are critical to have. Our bindings will cover interactions 
with the relay-chain and the initial parachain and as such depends on them. 

Governance: Initially, this will be a meta-protocol on the relay-chain for managing exceptional events such as 
hard-forks, soft-forks and protocol reparameterisation. It will include a modern structure to help manage conflict 
and prevent live-lock. Ultimately, this may become a full meta-protocol layer able to enact changes normally 
reserved for hard-forks. Requires the relay chain. 

Interaction platform: A platform by which “typical” users are able to interact with the system, along with 
minimal functionality to facilitate common tasks such as entering the bond process, voting, nomination, becoming 
a validator, fisherman or collator and staking token transfer. Depends upon having a functional relay-chain. 

Light clients: Light-client technology for both the relay-chain and any parachains developed. This will allow 
clients to be able to gain information regarding activity on the chains with a high degree of trust-freedom and 
without any substantial requirement of storage or bandwidth. Depends upon the relay-chain. 

Parachain UI: A multi-chain, multi-token wallet and identity management system. It requires light-client tech- 
nology and the interaction platform. This is not needed for any initial network deployment. 

On-chain Dapp services: There may be various services that will need to be deployed on any initial parachains 
such as registration hubs for APIs, names, natural-language specifications and code. This depends on the 
parachain but is not strictly needed for any initial network deployment. 

Application development tools: This includes various bits of software required to help developers. Examples 
include compilers, key management tools, data archivers and VM simulators. Many others exist. These will 
need to be developed as required. Technologies will be chosen partly to minimise the need for such tools. Many 
will not be strictly required. 

Ethereum-as-a-parachain: Trust-free bridge to Ethereum and back again, allowing posted transactions to be 
routed from parachains into Ethereum (and treated like any other transaction of external origin) and allow 
Ethereum contracts to be able to post transactions to parachains and the accounts therein. Initially, this will 
be modelled to ascertain feasibility and get any structural limitations based around the number of validators 
required by the consensus process, a component on which it is dependent. A proof-of-concept can be built 
following this and final development will be dependent on the relay-chain itself. 

Bitcoin-RPC compatibility layer: A simple RPC compatibility layer for the relay-chain allowing infrastructure 
already built using that protocol to be interoperable with Polkadot and as such minimise effort for support. A 
stretch goal requiring the relay-chain. 
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Web 2.0 bindings: Bindings into common Web 2.0 technology stacks to facilitate the usage of Polkadot infras- 
tructure with legacy systems. A stretch goal dependent on the initial parachains and any on-chain infrastructure 
to be exposed. 

zk-SNARK parachain example: A parachain utilising the properties of zk-SNARKs in order to ensure identities 
of transactors on it are kept private. A stretch goal dependent on the relay-chain. 

Encrypted parachain example: A parachain that keeps each item of state encrypted and signed. These ensure 
the enforcement of access controls over inspection and modification of the data therein allowing commercial 
regulated operations to conform as necessary. Would include proof-of-authority mechanisms to allow Polkadot 
validators to guarantee some degree of correctness of state transitions without gaining exposure to the underlying 
information. A stretch goal depending on the relay-chain. 

Trust-free Bitcoin bridge: Trust-free Bitcoin “two-way-peg” functionality. This would possibly use threshold 
signatures or alternatively an n of m multi-signature Bitcoin account together with SPV proofs & specialised 
fishermen. Development is predicated on an initial feasibility analysis giving a favourable result. Some additional 
functionality may need to be added to (or unlocked from) the Bitcoin protocol to support this functionality. 

Abstract /low-level decentralised applications: Trust-free token exchange, asset-tracking infrastructure, crowd- 
sale infrastructure. 

Contract language: Certainly not an integral part of the project, but a nice stretch-goal nonetheless. Would 
include a safe contract language together with tutorials, guidelines and educational tools. It may include means 
of making formal proofs as per the original Solidity language vision or could be based around some other 
programming paradigm which helps minimise critical process errors such as functional programming or condition- 
orientated programming. 

IDE: Based on the contract language, this would facilitate editing, collaboration, publication and debugging of 
contracts on the parachains. A far stretch goal. 


APPENDIX B. FREQUENTLY ASKED QUESTIONS 


Is Polkadot designed to replace (insert blockchain here): No. The goal of Polkadot is to provide a frame- 
work under which new blockchains may be created and to which existing blockchains can, if their communities 
desire, be transitioned. 


Is Polkadot designed to replace w crypto-currency here): No. Polkadot tokens are ni intended 
nor designed to be used as a would make a bad currency: g 
a q 


Why anes stale token Wan reflect enone: This is a mechanism realised by the fact that they 
underpin the network’s security. As such their value is tied to the overall economic value that Polkadot provides. 
Any actors who gain overall value from Polkadot operating correctly are incentivised to ensure it continues to 
do so. The best means of doing so is to take part in the validation process. This generally implies ownership of 
staking tokens. 


